home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20020314-20021006 / 000002_fdc@columbia.edu_Thu Mar 14 13:31:47 EST 2002.msg < prev    next >
Text File  |  2020-01-01  |  5KB  |  101 lines
  1. Article: 13267 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
  3. From: fdc@columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: Experience with K95 over satellite links
  6. Date: 14 Mar 2002 13:31:02 -0500
  7. Organization: Columbia University
  8. Lines: 84
  9. Message-ID: <a6qq96$efo$1@watsol.cc.columbia.edu>
  10. References: <c4914b87.0203140931.41ac24bc@posting.google.com>
  11. NNTP-Posting-Host: watsol.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1016130663 10236 128.59.39.139 (14 Mar 2002 18:31:03 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 14 Mar 2002 18:31:03 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13267
  16.  
  17. In article <c4914b87.0203140931.41ac24bc@posting.google.com>,
  18. satprof <satprof@altavista.com> wrote:
  19. : Following my posting at the end of Jan, 2002 about evaluating Kermit
  20. : for a project to transfer ~70MB of data nightly via a double(!)
  21. : satellite hop, it might be useful for others in the future to hear of
  22. : my experiences.
  23. : ...
  24. : The approach I adopted was to set up the K95D.EXE 'daemon' on the
  25. : machine holding the data & to script the file transfer on the machine
  26. : to which the data was to be sent. Before leaving for Africa, I tested
  27. : the script (based on the 'reliable file transfer' script in the K95
  28. : 'scripts' folder) between my home in France & my office in Geneva.
  29. : With an ADSL link at home (& T3 at the office) my tests showed around
  30. : 20KB/second. (Ping time ~ 40mSec)
  31. : 
  32. : However, on arrival in Africa, I couldn't achieve more than about
  33. : 3KB/second in practice. The receiving end showed only that a single
  34. : window was in use, but that is apparently normal at the receiver.
  35. :
  36. Right.  The reciever's window size goes up only when a packet is missing.
  37. When the missing packet eventually shows up, it can write out its window
  38. to disk and the window size goes back to one.
  39.  
  40. : The
  41. : sending end showed that sliding windows were in use, but only 5 out of
  42. : 30 possible. (Packet size settled down to 4000/3999; streaming was off
  43. : to ensure block checking & the Fast macro was invoked.)
  44. :
  45. That means the sender was receiving acknowledgements within five packet
  46. times.  The window never grows larger than it needs to, and the sender
  47. is pushing out packets as fast as it can.  My guess is that your modem
  48. was flow-controlling the PC, which would happen if the PAD was
  49. flow-controlling the answering modem, which is not a stretch.  Remember,
  50. the PAD is taking each 4K packet and segmenting it into 32 128-byte
  51. packets and sending them over an X.25 network with a window size of 7,
  52. using go-back-to-n retransmission strategy rather than selective repeat
  53. like Kermit.  If the satellite links are dirty or lossy, this can result
  54. in awful (but still presumably error-free) end-to-end throughput.
  55.  
  56. If you use hardware flow control, the modem lights would tell the tale.
  57.  
  58. If you weren't using modems at all, the same principals would still apply.
  59.  
  60. : The relatively slow speed was a bit of a disappointment, but it was
  61. : overcome by initiating 5 concurrent instances of Kermit, and
  62. : transferring the data in parts.
  63. :
  64. That's just the right thing to do in a situation like this.  Each
  65. connection is its own virtual circuit within the X.25 cloud and so does
  66. not affect the others.
  67.  
  68. : The prime reason for the post is to record this for others, but I'd
  69. : also like to thank Frank & the others in the group for their input at
  70. : the beginning of the project.
  71. : 
  72. Our pleasure :-)
  73.  
  74. : If anyone has any ideas about how to increase the no. of windows
  75. : actually used, I'd like to try that out.
  76. :
  77. See above.  Modern Kermits have a default maximum window size of 30, and
  78. they use all the slots they need to use at any given moment.  If the
  79. number of slots used is low and your throughput is also low, it means
  80. Kermit is being throttled by the communication medium.
  81.  
  82. If the Kermit-to-Kermit connection was over TCP/IP as I assume it must
  83. have been since K95D.EXE is involved, you might have done better to
  84. simply allow streaming.  On the other hand you might also have done
  85. better by making a directly dialed connection so as not to have the
  86. differing transport strategies of Kermit, TCP/IP, and X.25 all fighting
  87. each other at once.
  88.  
  89. : I also tried to get K95D.EXE
  90. : to run as a WINNT service, but without success, so would be interested
  91. : to know if anyone has managed this elsewhere.
  92. : 
  93. This is quite straightforward in the new release, which is in its
  94. final days of Beta testing:
  95.  
  96.   http://www.columbia.edu/kermit/k95next.html
  97.  
  98. Thanks for the terrific report -- I wish everybody would do that!
  99.  
  100. - Frank
  101.